Once upon a time, when networking was new, life was simple. Users never pushed LANs to their limits. Nothing ever broke.
In those days, network equipment was managed by terminals. If you wanted to find out how hard one of your bridges was working, or if you wanted to reconfigure your router, you plugged your dumb terminal directly into the device, typed in commands, and saw the results on your screen. This was called 'out-of-band management'.
This quickly became a pain.
Sites with lots of networking equipment sitting in many different locations had to either invest in heavy-duty sneakers or run special management cables from each piece of equipment to an array of switchboxes in a central network management area.
Even then, you were stuck with a keyboard-and-screen interface, which made it really difficult to automate any portion of your work.
And if you were foolish enough to buy your equipment from more than one company, you discovered that everybody had their own unique incompatible way of entering commands and displaying results. Even though information could flow seamlessly around your networks, you had to manage the flow in vendor-specific parts.
So in the mid-eighties, the network equipment vendors and users got together and created SNMP, the Simple Network Management Protocol.
This solved two problems:
(1) SNMP would let you manage your network equipment 'in-band' - you could trash all those snaking management cables and piled-up switchboxes and dumb terminals, instead you could talk to your network equipment over the network itself
(2) SNMP provided some standard ways to talk to your equipment - now no matter who made your equipment, it would respond the same way to the same commands
Each of your SNMP-manageable devices has a little 'SNMP agent' built into it, which most of the time does little except keep watch on the internal operations of the device. Each of those agents is network-connected, though, and they can respond to requests coming from 'SNMP manager' programs running elsewhere on the network.
The basic idea is, the agents are simple and cheap and don't do much; the managers can be as expensive and fancy as you want.
Actually, SNMP is two things -
first, it defines a communications protocol: how the managers and agents talk to each other
second, it requires a common set of object definitions: what the managers and agents can talk about
There are only five commands in SNMP - three (Get, GetNext, and Set) sent by managers to agents, and two (GetReponse, Trap) sent by agents to managers.
Most managers will spend their days periodically sending Gets (or powerful GetNexts) to the agents they know about, asking about certain commonly-known objects, and the agents will send back GetResponses with the current value of each of those objects. It's a manager's job to gather and organize and interpret those responses.
When your manager lets you change a configuration item on one of its managed devices, it will usually do so by sending an appropriate Set command to the device's agent.
And occasionally when an agent notices that something weird has happened, like if one of its interfaces has stopped working, it will send a Trap notification to its manager(s).
(Actually, SNMP conversations can take place using several networking protocols - IPX and AppleTalk for example - but most agents are not too smart and can only speak SNMP using the UDP portion of the TCP/IP protocol)
The people that put together SNMP felt obliged to add some administrative capability in the form of 'communities'.
These days, agents will have at most two communities defined, one for managers that need read-only access to the objects that the agent knows about, one for managers that need to be able to issue 'Set' commands to modify those objects.
The community names are kind of like weak passwords - a manager will need to know a read or a read/write community name for each of the agents it's going to manage.
In the real world, though, the community names offer no practical security; as a result, most agents on networks today allow read-only access to managers via the common default community name 'public'.
It's not enough to have a standard set of commands, if the managers and agents aren't able to use the same names and the same meanings for the things they talk about. You don't want to have to use a different manager for each brand of equipment you own.
So it's an important part of the SNMP world to agree on those names.
This is done through 'MIBs' - Management Information Bases - which are formal dictionaries that name sets of manageable objects and define what each object means.
The standard SNMP MIB, called 'MIB-II', defines the basic objects that relate to network management, as well as objects relating to the 'TCP/IP' network protocol.
Every SNMP agent that's out there supports a good chunk of MIB-II.
There are now hundreds of other MIBs, which are actually extensions of MIB-II.
Some of these are specific to single vendors ('the Cisco MIB', 'the Novell MIB'), some are intended to be used by everybody ('the Repeater MIB', 'the AppleTalk MIB').
Each of the SNMP agents on your network may support one or more of these MIBs.
So, an example:
in the old days, every networking company had a different way to ask its devices how long they had been running, and a different meaning of 'how long' (seconds? minutes?).
Now, since MIB-II defines an object called "sysUpTime" as being the time in hundredths of a second since the agent was started up, and since all your SNMP agents support MIB-II, a manager can send a "Get sysUpTime" to each agent on your network, and get a standard sensible response from all of them.
And since MIB-II also defines a table of objects relating to IP routing, if a manager is smart enough it can poll the SNMP agents on all the kinds of IP routers on its network and compile the results to create a logical map of the network.
If you've been following the trade papers over the last year, you'll know the network standards people have been working on finalizing SNMP version 2.
All you need to know about SNMPv2 at this point is - there's been a huge battle, there are two warring versions of the standard, few people have deployed version 2 support so far, the world may fall back to a compromise SNMP v1.5, but it's all still up in the air.
Your best bet is to take a course. Not knowing anything much about SNMP, and with low expectations (don't tell anybody but it was the end of the year and I was trying to use up our training budget), I took a 2-day intro-to-SNMP course and it was great.
I just took a quick look through the web and I didn't see any good tutorial documents there.
The comp.protocols.snmp SNMP FAQ, though, has a decent list of tutorial and reference books, as well as some answers to frequently-asked questions:
FAQ part 1, and
FAQ part 2
/Donald Matthews
20 June 96